GDB"> X"> dmesg"> boothack"> amiboot"> HDToolBox"> ]> $Date: documentation in progress Jesper Skov

jskov@cygnus.co.uk

1998Jesper Skov This document contains frequently asked questions (and answers) about &linapus; (&linux; for &amiga; &pup; Systems) as well as general documentation of the &linapus; port. Hello! Welcome to the user part of &thisdoc;. I hope you will find what you are looking for. It's very important that this document, presumably being the first stop for new &linapus; users, is good enough to get you and the ones after you from &ados; to &linapus; with as few problems as possible. Please send suggestions for improvement to the maintainer at apus@linux-m68k.org. Do not send questions to that address - there are better places to ask for answers to your questions. Please read on. Thanks, Jesper The &linux; port for APUS (&amiga; &pup; Systems) was started in 1997 with support from &p5; who provided 3 developer boards to Jes Sørensen, Roman Zippel and Jesper Skov. Initially it seemed that the proprietary information needed to make the port would make a bad mix with the open source model of &linux;. Indeed, it postponed the public release of &linapus; somewhat, but it all worked out in the end. &p5; have approved all the released information and, sparse commenting aside, all source code changes are freely available. I refer to the following ports of &linux; in this document: &linm68k; The port for the Motorola &cpum68k; CPU family. This is what you would use for running &linux; on an &amiga; without &pup;. It is also the port that &linapus; is based on, since all the drivers are the same. &linppc; The port for the Motorola &cpuppc; CPU family. The home of this port is at www.linuxppc.org. This port has multi-machine support, including PMAC, PREP, CHRP and partially APUS. &linapus; The port targeted at &amiga;s with &p5;'s &pup; hardware. With time, it will be a proper part of &linppc;. It may also become a base for the support of &cpuppc; cards from other &amiga; vendors. I will try to keep this document up to date, but if you find something that is obsolete or wrong, please let me know. Things marked with FIXME are known to be incomplete or (maybe) wrong. New changes in the document are marked with colors. Recent changes are red, and as the changes age they fade to blue and then black over a period of 14 days or so. Sections containing these colored changes will be dated so they can be easily identified from the table of contents. The colors work fine (IMO) with the default Netscape colors. If you use a customized color scheme, you might want to generate the HTML pages without the colors: use the DocBook db2html and the file faq.sgml from the docs directory at &sunsite;. Precompiled kernel images and a special version of &amiboot; (called &boothack;) can be downloaded from &sunsite;. Before you download anything, you should read and to prevent yourself from getting a nasty surprise. Also, I suggest you start by downloading only what is needed to get a minimal system installed (see ) - if this is working you can then download the applications you want to run. The kernel archives at &sunsite; (see ) are named vmapus-YYMMDD.lzh and contain three files: vmlinux (the actual kernel image), System.map (a list of symbols/addresses in the kernel) and .config (describing how the kernel was configured). You only need the kernel image to boot &linux;, but the other files may help track down bugs. Please read for information about how you can use a kernel dump and the System.map file to help yourself or others locate a bug. It is not customary to provide precompiled images of a developer kernel, but I have chosen to do so because not everybody have the disk space to install two separate systems (i.e., a &linm68k; system just for compiling &linapus; kernels). When &linapus; becomes more stable (that is, when enough drivers are reported working) I will stop providing the precompiled kernels. People who want the bleeding edge stuff should then recompile their kernels themselves (see ). The precompiled kernel image includes drivers for the hardware listed below. The drivers are exactly the same as in &linm68k; so they will not work better (or worse, hopefully) and you need to take the same precautions with some of the drivers (e.g., CyberVision) as you would in &linm68k;. Consult the &linm68k; FAQ (see ) if you have problems. A list of drivers that are known to work can be found in . DISPLAY BLOCK CHAR NET SCSI OCS, ECS, AGA, CyberVision, CyberVision/3D, PM2 (CyberVision/PPC) The driver included in the precompiled kernel is an old beta. If you want the up-to-date version get the latest sources from the PM2 webpage (see ). Don't expect the precompiled version to behave as described on the webpage! , RetinaZ3, Clgen &amiga; floppy, A1200/A4000 IDE, IDEDoubler, Buddha &amiga; serial, &amiga; keyboard, &amiga; mouse, &gvp; IO extender (ser), MultifaceIII ser, Whippet Ariadne, AriadneII, A2065, Hydra A3000, A4091+A4000T You have to disable the use of BATs to map main memory. Add "nobats" to your kernel options. There are still some stability problems with this driver under &linapus;. , BlizzardPPC You have to disable the use of BATs to map main memory. Add "nobats" to your kernel options. , A2091, GVP11 If you have hardware for which you would like to see an existing &linm68k; driver included, please let me know. You should restrict your request to something you need to get your system installed as the precompiled kernel is already pretty big. Some drivers will be include for testing purposes (like sound) and be removed again when they have been reported as working. The kernel also includes these software drivers: FS PARTTBL PROTOCOLS MISC affs, dos, ext2, iso9660, minix, nfs, proc, vfat, hfs amiga, msdos, mac ppp, slip ram disk, z2/motherboard swap, loop In this chapter I will try to help you through the steps of installing a &linapus; system. This is based on the &rhppc; system - if you want to install another package distribution or compile applications yourself, you are pretty much on your own. The only reason for describing how to install a &rhppc; system and not &debian; is that &rhppc; seems to be (at the moment) the primary system used by &linppc;. By the way, &rhppc; is not coordinated by &rh; but by &linppc; developers. It might be a good idea to read this entire chapter before you start downloading anything - so you know what is required for what you want to do. If you don't know how to do some of the things mentioned here (or are unclear about something) you should get an install help text. You should be able to find several by looking for links at www.linux-m68k.org. If you have corrections, additions or comments to this, please let me know. Your feedback is important for this chapter since new users (after you there may be others coming this way, you know!) will probably try to follow this - any misinformation or errors no matter how trivial should be corrected. You need to get the files found in , and in . You should get the following files (leave them in the same directory): misc/kernel-options.txt misc/ramdisk.image.gz The ramdisk.image.gz is primarily used to test that &linapus; actually boots. If you know it boots, don't bother downloading it. latest/bhYYMMDD.lha latest/vmapus-YYMMDD.lzh install/redhat/apus-rh-ramdiskimageYYMMDD.gz Unpack the archives (the version of lha I use under &linux; appends the suffix .lzh and I'm bound to forget renaming them to .lha - so I don't): lha x bhYYMMDD.lha lha x vmapus-YYMMDD.lzh Leave the ram disk compressed, or it will not be usable. This section describes how to boot the kernel. The basic command required to boot &linapus; using a ram disk as main file system is: bootstrap --apus -k vmlinux -r ramdisk.image.gz root=/dev/ram The root=/dev/ram option tells the kernel to read its data from the ram disk, -k specifies the kernel image to boot, -r the ram disk file and --apus that the &cpuppc; should be the CPU starting the kernel. The above is how you would boot on a simple system. When issuing the command bootstrap you may need additional parameters (at the end) for the kernel to work on your system - this is just the same as if you were booting a &linm68k; system. Display selection, display resolution, SCSI driver options and other things are controlled by such additional options. There are two specific &linapus; kernel options: 60nsram Use this to remove RAM waitstates. It requires 60ns RAM. nobats Use this to prevent the use of BATs for mapping of main memory. Selecting this incurs a small performance overhead, but some drivers depend on each memory page being individually mapped (A4000T/A4091 SCSI drivers). Other kernel options exist, but are shared with &linm68k; and other ports so I don't describe them here. One of the files you should download (kernel-options.txt) describes the options you can use. The &linm68k; website/FAQ should also contain some general information about the boot options. A ram disk image is used to get started. The ram disk contains a minimal &linux; system from which you prepare your disks. When you have done this (described in sections below), you will normally use root=/dev/xxx (where xxx is the root partion) to boot your &linapus; system. Notice that booting the &linapus; kernel might blank the display for as long as 30 seconds depending on the &cpuppc; speed. Some people have reported problems with copying the ram disk (and kernel) to RAM: before booting and must use a disk partition for the files. Others need to copy the files to RAM:, especially &blzppc; owners who use SCSI disks. Additional to options for making your hardware run smoothly with &linux;, you may need to restrict your memory configuration for &linapus; to work correctly. &linapus; only supports one block of primary memory which should be the memory on the &pup; board. It would be possible to support mutiple blocks, but since there is such a big performance penalty in using other system memory than the one on the &pup; board, it doesn't make sense. The problem is that &linux; uses memory much more aggressively than &ados; so all memory will be used constantly. Because of this it is not possible to prioritize memory blocks as it can be done under &ados;. This means that you cannot guarantee that the most CPU intensive applications actually run in the fastest memory block in the system. For this reason, &linapus; only support one block of primary memory -- the fastest. See for a way of using additional memory. If you have multiple memory blocks, the one on the &cybppc;/&blzppc; will usually have the highest priority and be selected by default. Unfortunately, this is not foolproof and you may have to explicitly define the block to be used. You control the memory &linux; can see by using a memory config file: add -m file after the --apus option. This file should contain 2 lines: on the first the size of your chip memory, on the second the starting address of the memory and its size. Here's a single example. 2097152 0x08000000 33030144 The format of memory files actually allow more memory blocks to be specified (since it was created for &linm68k;), but only one memory block can be used in &linapus;. If you have more than one block of memory in your system, you must specify the block located on the &cybppc; or &blzppc; card. You should be able to get the required numbers from showconfig or a similar tool under &ados;. Notice that the size of the memory is 512kB less than what you would expect (33030144 is 31.5MB). This is normal and required. The 512kB block is used to hold the &cpuppc; exception vector table and other &p5; stuff. If you are using the Shadow hardware on your &p5; &cybppc; or &blzppc; board to remap the &ados; ROM to RAM, you should either disable this before booting &linapus; or make sure the memory size reflects this mapping: the memory size reported by bootstrap should be 1MB smaller than the amount of RAM in your system. If it is only 512kB smaller, you have to use a memfile, specifying the total amount of RAM less the 1MB. The newer kernels (980725+) will detect the ROM shadowing (based on the memory size) and will avoid that chunk of memory. This means 512kB of your memory will remain unused in &linapus;. If you do not subtract the 512kB when specifying the size in a memfile, the kernel will not boot! Even though only one block of memory can be used for primary memory in &linapus; you can use other memory resources as a fast swapping device. Using slower memory for swapping makes sense; your applications are always running in the fast primary memory on the &pup; board, but the slower memory is still providing a much faster page swapping service than the harddisk would. You specify a block of memory for swapping by adding a line to the memory file (or by relying on the default &ados; priority ordering of the memory blocks). On my box, I have 32MB on the &cybppc; and 8MB on the motherboard of my A4000. The default &ados; ordering matches this memory file: 2097152 0x08000000 33030144 0x07800000 8388608 Again, the default &ados; priority ordering may do the correct thing for you. If not, you have to use a memory file. After booting, you need to tell &linux; to use the new swapping device. First you must add a new device node: mknod /dev/fastram b 37 4 Each time you boot you have to initialize the memory area (it doesn't keep its state over reboot as your swap partition does), and enable it with a higher priority than the swap partition (put the lines in /etc/rc.d/sysinit or similar). mkswap /dev/fastram swapon -p1 /dev/fastram In the above only a single memory chunk is used for swapping. The z2ram device can only handle one chunk at the moment. However, it can select other than the second chunk of the memory list; minor numbers 4, 5, 6, and 7 select memory chunks 2, 3, 4, and 5 respectively, chunk 1 being used as primary memory. Before you go any further and start downloading packages, you should make sure that you can actually boot &linapus;. Get the required files for booting and follow the boot instructions above. If all goes well &linapus; should boot, displaying a picture of an (alcoholic :) penguin (called Tux) in the upper left corner of the screen. Text should be output, showing the progress of the boot, eventually leaving you with a # prompt and a blinking cursor (unless you boot with debug=<whatever> in which case you will not see the text, only Tux and the prompt). Your disk partitions should be recognized, notifying you of this fact with some output similar to: Partition check: hda: hda1 hdb: hdb1 hdb2 hdb3 hdb4 This is a good sign as it means the disk driver is probably working. Depending on your hardware configuration you might not see this. Either because there exists no driver for the disk controller, or because the driver has not been included in the prebuilt kernel you booted. In both cases, report your finding to the &linapus; kernel mailing list for advice. The ram disk contains a few tools that allow you to mount disks to see if they work as expected. This ram disk was used in an older installation scheme, but unless you really know what you do, you should use the &rh; installer. If you got this far, it should be safe for you to start downloading packages for a proper installation of your &linapus; system. Good luck! Text by Thomas Lohmann The partitions for installing &linapus; should be created using &hdtbox; which is included in &ados; since version 2.x. You need at least two partitions, one for SWAP (as big as your memory is) and one for ROOT. You have to set the advanced options using &hdtbox; to ON and set the filesystem type to "CUSTOM FILE SYSTEM", the identifier has to be set as follows: 0x4c4e5800 (LNX/0) For all major &linux; partitions. 0x53575000 (SWP/0) For the swap partition. You can also set "Reserved Blocks at" to 0 for both beginning and end, but this should not be necessary. You can get precompiled &rh; &rpm; packages from www.linuxppc.org (see ) or its mirrors. You can also buy the CD-ROM (details at the WEB site). &rhppc; does not explicitly support &linapus;. None of the &linapus; developers are affiliated with the &rhppc; developers. This help is offered "AS IS" -- without any guarantees of your success. Text by Ken Tyler The &rhinstaller; simplifies the process of partitioning, formatting installing and configuring the &linux; &rhppc; distribution. No previously installed &linux; is required, the installation is started from &ados; by booting a kernel with the &linapus; ram disk image as the root filesystem. The &rhinstaller; has been used to install from a hard disk partition to other partitions on the same drive. Christophe Decanini reports that CDROM, FTP and NFS work. Note: See for a list of applications that are known to fail. A kernel. The latest &linapus; &rhinstaller; ram disk image (usually named apus-rh-ramdiskimageYYMMDD.gz in ). &rpm;s, base files and README.installer. Available on the &linux; &rhppc; CD-ROM or from ftp.linuxppc.org and mirrors. The base files required are comps.pmac, hdlist, skeleton.cgz and uglist. A few moments spent reading this docment, especially the Problems at the end of this section. &rpm; is the acronym for &rh; Package Manager. This is a standalone program that installs software on to a &linux; system. Files intended for use by &rpm; have the extension .rpm. The &rhinstaller has a library version of the RedHat Package Manager in the install ramdisk.image. The &rhinstaller; can partition and format hard disks, but depending on which install method you use you might need to partition your hard disk first with &hdtbox;. On a single drive system, an AFFS &ados; partition is needed to hold the &rpm;s in addition to the required &linux; and swap partitions. On a system with two or more drives, or when using the other install methods the installer can do the partitioning and formatting of the drive(s). On the AFFS drive or partition a directory RedHat with subdirectories RPMS and base should be created. The base directory should hold the comps.pmac, hdlist, skeleton.cgz and uglist files. The RPMS directory is the place for the collected &rpm;s. The suggested &rh; minimum system is about 25MB of &rpm;s which needs about 70MB of &linux; disk space. Read the README.installer for info on the comps.pmac file format. Basically there are two types of line; separator lines and &rpm; prefix lines. Separator lines start with a digit or the word 'end' and divide the &rpm;s into groups, &rpm; prefix lines are partial &rpm; names. An indented &rpm; prefix line implies that the &rpm; specified by the preceding non-indented line is required. If the comps.pmac file has entries for &rpm;s that don't exist in the RPMS directory the installer complains about them but will work, but to avoid saying OK to many warnings edit the comps.pmac file to include only the &rpm;s you have. The long filenames of some &rpm;s are chopped at the &amiga; 32 character limit but this is not a problem since &rpm; will scan the packages for their full name. Copy the apus-rh-ramdiskimageYYMMDD.gz to RAM: and boot specifying: -r ram:apus-rh-ramdiskimageYYMMDD.gz root=/dev/ram in addition to the usual --apus, -k, and -m options as required. I use (all on one line) : boothack --apus -v -d -m memfile -k ram:vmlinux -r ram:apus-rh-ramdiskimageYYMMDD.gz root=/dev/ram If all goes well a window asking if you have a color monitor will appear. (Respond to the windows with CR to enter, SPACE to toggle on/off and TAB to move between buttons, cursor arrows to move up and down lists.) Now comes a succession of windows guiding you through the installation. Reply to these to suit your system. Choose install at the install/upgrade window. Eventually you should get to the window asking what packages to install. Select what you require or the "everything" option at end of the list. After the Package install finishes there may be much disk activity as the &rpm; database is created. A few more windows, networking timezone and root password. Finally an "OK to reboot" screen should appear but wait till the disk activity stops before rebooting. During the the install, CTRL-Z brings a shell up, entering exit returns you to the installer. ALT-F1 to ALT-F4 select installer, a shell, installer log and kernel log virtual consoles. To get F11 to F20 use SHFT-F1 etc. To create a list of the suggested required &rpm;s for a minimum system, take the &rpm; prefixes in the '1 *beforeskel*' and the '1 Base' sections of the comps.pmac file and expand them into the full &rpm; name as contained in the RPMS directory. Flashing console problem. The current CD (as at 27-Oct-98) writes an /etc/inittab that attempts to start X at the default run level of 3 rather than run level 5. As kernels from 2.1.120 to the 981026 release have problems with X on some hardware, the result is alternating flashes of login screens and blank X screens. To avoid this, either get a 981031 or newer kernel, or fix the installation: when the installation finishes don't respond to the "Congratulations" window but hit ALT-F2 and edit /mnt/etc/inittab. All that needs to be done to /mnt/etc/inittab is to swap the comment '#' char on the last two lines of the file. To run any of the newly installed editors you need to specify a full path, the installed system is on /mnt. Now hit ALT-F1 and confim the "Congratulations" window. Thanks to Kolbjørn Barmen for suggesting this approach. If you have already installed the the X components and are seeing the flashing console, you need to login and edit /etc/inittab and make the above change. Can be difficult to login through the flashing but it can be done. Look at the top left of the screen to see the password characters that don't get to the password prompt (retype these). The first version of the installer was incorrectly named apus-rh-ramdisk.image130698.gz, should have been called apus-rh-ramdisk.image980613.gz. NOTE: apus-rh-ramdisk.image981003 requires the comps file to be named comps.pmac, for earlier versions of the installer, rename comps.pmac to comps. If you have a 4.2 CD February 98 use apus-rh-ramdisk.image130698.gz, if you have the 5.0 CD or try the other install methods use apus-rh-ramdisk.image981003. The 130698 installer has problems with the 'noarch' files in the 5.0 distribution. Three of the &rpm;s on the 4.2 CD have errors when installing. dailyscript-3.1-2.ppc.rpm writes a message over the progress screen, latex2html-96.1.revh-4.ppc.rpm and xmahjongg-2.0-1A.ppc.rpm fail with install script failed. I have yet to do a full install from the 5.0 CD. Installing the suggested base was free of errors. Some users have a reported a 'missing kernel error' when attempting to install from downloaded &rpm;s. The installer tries to put a kernel into the /boot directory. There is no reason to do this as the kernels available on linuxppc.org are not &linapus; kernels. To avoid this edit the comps.pmac file and remove the two (4.2) or three (5.0) lines kernel-prep, kernel-pmac, kernel-pmac-modules. Comments, feedback about success or failure most welcome, I read the &linapus; list daily. &rh; has released a CD set named Linux Rough Cuts, containing (unsupported) &rh; ports for (among other CPUs) &cpuppc; and &cpum68k;. The &cpuppc; installation is intended for MkLinux, but it's possible to use it for &linapus;. Basically you should follow Ken's instructions above. There are a few differences, primarily because the &rhrc; CD does not contain all the required install files. But follow the below instructions, and you should come out of it OK anyway. Get the file rh-roughcuts-981108.tgz from . It contains what you need to get started. The layout of the &rhrc; CD is wrong (for the &linapus; installer), and is missing files (probably because it's intended to be used from MacOS). You have to create a correct layout. You can do this in at least two ways; 1) install via FTP and create the correct layout on another Linux box using soft links (I did this) 2) install from harddisk, having copied the CD contents to a harddisk and added the extra bits. Below the tree structure of the directory I created on Concubine for installation on Cyber (-> is a soft link to the file or directory on the &rhrc; CD). During installation I set the FTP directory to the path containing RedHat you see as the top node below. `-- RedHat |-- RPMS -> /mnt/cdrom/RedHat/RPMS |-- TRANS.TBL -> /mnt/cdrom/RedHat/TRANS.TBL |-- base | |-- RedHat -> /mnt/cdrom/RedHat/ | |-- TRANS.TBL -> /mnt/cdrom/RedHat/base/TRANS.TBL | |-- comps.pmac | |-- hdlist -> /mnt/cdrom/RedHat/base/hdlist | |-- skeleton.cgz | `-- uglist |-- ppc -> /mnt/cdrom/RedHat/ppc `-- rpmcontents.gz -> /mnt/cdrom/RedHat/rpmcontents.gz The structure is found in the rh-roughcuts-981108.tgz archive; you might want to use it as a base. If you create it yourself, there are three files in there that you need to include: comps.pmac The comps file from the base directory of the disk. The two &rpm; packages MAKEDEV and dev have been moved down as the last to be installed due to some problem I couldn't track down. skeleton.cgz The skelton file from the &rhppc; installation containing a few extra files. uglist The skelton file from the &rhppc; installation. When you have this set up, installing is done exactly as with the &rhppc; CD. The text printed out before the login prompt is from the &linppc; skeleton, so it is somewhat misleading... You can get precompiled &debppc; &deb; packages from www.debian.org (see ) or its mirrors. Currently no &cpuppc; version of the &debian; CD distribution exists. Text by Michel Dänzer First of all, be aware that installing &debian; is quite a bit harder at the moment than installing &rhppc;. I mention this so nobody downloads lots of stuff and then has to give up frustrated. There is no CD-ROM release until now, the guys at &debppc; want to wait until it's virtually equal to the i386 &deb;. However, if you've got the time and will to experiment a little, give it a go! You won't be deceived :-) Please read all the instructions carefully before you start. You need to have an empty ext2 partition, which will be the root partition. You will probably need a swap partition and maybe others as well. It's up to you how you arrange things. You might want to read first. Get a base tarball. I have uploaded one to sunsite, it should be in . Get the rd-deb-install.gz ramdisk there. You might want to download or at least look at the other files there as well. Unpack the base tarball. I'll quickly describe how to do this with the rd-deb-install.gz. Boot the ramdisk. Init will ask you to enter the runlevel, type 'S' and press enter there. Now you'll see a rather ugly prompt, however, it's bash, so you have all the commodities like command history etc. Format the root partition (I call it /dev/sda2 here because that's my root partition at home; replace it with your root partition): mke2fs /dev/sda2 Mount the soon-to-be root partition at /mnt/root: mount -t ext2 /dev/sda2 /mnt/root Mount the Amiga partition containing the base tarball at /mnt/amiga (Again, replace /dev/sda4 with your partition ;): mount -t affs /dev/sda4 /mnt/amiga CD to the base tarball's directory and unpack it with: tar xvzpf base2_1.2.0.11.4_1998-10-15.tgz -C /mnt/root The p switch is vital, it sets all permissions correctly. Remove the unconfigured.sh script which would prevent the thing from booting (Note: if you're unlucky and have the first version of rd-deb-install.gz, you will have to use /mnt/root/bin/rm): rm /mnt/root/sbin/unconfigured.sh You need to create /mnt/root/etc/fstab, or else init won't be able to mount the filesystems at boot time. You can use joe to do that: joe /mnt/root/etc/fstab Press CTRL-K and then H for help. CTRL-K X to save the file. FIXME: Unfortunately, there is no template fstab in this base tarball anymore. If you don't know how to set it up, refer to other FAQs (I would be glad if someone could add an example here - or maybe I'll do it sometime :). Now you're set for a first boot into your shiny new &debian; root partition! Remember to unmount all filesystems before rebooting. umount /mnt/root umount /mnt/amiga It should boot right through to the login screen. You must login as root. Now you can start installing additional packages. All the needed stuff like pppd, ftp, etc. is there, so the main problem remaining is probably setting up pppd. Try pppconfig, a tool for that purpose with a User Interface. If that doesn't work, bad luck, check out the PPP-Howto at http://sunsite.unc.edu/LDP/HOWTO/PPP-HOWTO.html Once this works, dselect can download the packages you want automatically via FTP. Just choose FTP as the installation method. The main server is ftp.debian.org, but you'll probably prefer a mirror close to you. Read http://www.debian.org/misc/README.mirrors for a list. There's also a mirror at &sunsite; in /mirrors/ftp.debian.org. The distribution directories are debian/dists/unstable/main and optionally debian/dists/unstable/contrib and debian/dists/unstable/non-free. The location of the non-us files varies from mirror to mirror. You should update the libc and libstdc++ packages ASAP. This may break some packages, just update them to the latest version. E.g. you'll probably have to update the dpkg and tar packages. Congratulations, you should be using &debppc;! ;-) Unfortunately, you can't get X to work with the packages from the official FTP archive. Try the packages Sven built for you in . You need at least the xbase, xbase-clients, xfonts-base, xlib6g, xserver-common, xserver-fbdev and xterm packages. Install them directly with dpkg: dpkg -i <path to the files>x*.deb You also need a window manager; twm in is a very simple one to start, there are lots in the official archive. Some &rhppc; packages don't mix well with &linapus;. Please help me keep this list up to date so people don't have to download useless packages. The kbd* packages messes up the keyboard layout. Do not install them. Supposedly there are &amiga; keyboard patches for the recent kdb packages. I have not tried it myself though. Emacs-nox core dumps. This is a generic problem. The emacs compiled with X libs works fine. Gpm requires a small patch to be working. This is available from (provided by Holger Jakob). The patch is not needed for Gpm version 1.16 and above. You may also have to add MOUSETYPE='BUSMOUSE' to /etc/sysconfig/mouse. This chapter contains a few random notes on applications for &linapus;. You can get precompiled software for a complete system in both &rh; and &debian; packages (see ). The thing to remember when looking for applications is that &linapus; is binary compatible with &linppc; so you should have no problems finding software. Some commercial applications are also available for &linux;, but only in binary form. You would have to persuade the company to start shipping &cpuppc; compiled binaries in that case. I can imagine some of the other &linppc; sites would be coordinating such efforts, or at least it seems like a good idea to do. In order to run &x; you need to get a version of the &x; server compiled for &cpuppc; with support for the &amiga; hardware. Luckily, such a server is provided by Geert Uytterhoeven at www.cs.kuleuven.ac.be/~geert/bin/XF68_FBDev-ppc-19981017.gz (You might find a newer version than this). date990322 You should also get fbset from Geert's site: www.cs.kuleuven.ac.be/~geert/bin/fbset-19990118.tar.gz (again, there may be a newer version). This file may also be useful: www.cs.kuleuven.ac.be/~geert/bin/fb.modes.gz Unzip the &x; server and copy it to /usr/X11R6.3/bin/X. Now get the example XF86Config file from and copy it to /etc/XF86Config. Next, you have to create some &amiga; specific devices which are not included in the &rhppc; packages: cd /dev mknod fb0current c 29 0 mknod amigamouse c 10 4 ln -s fb0current fb0 ln -s amigamouse mouse Now you should be ready to start up &x; by issuing the command "startx". There are a few more details to sort out if you want to run &x; on a graphics card. This text is specific to CyberVision and CyberVision/3D -- but it might help you get &x; running on other cards. Please let me know of your success if you try that. Note: You have to use the same pixel clock under &linapus; as you use under &ados; Text by Jeffrey W. Davis I just wanted to inform everyone that &linapus; and the CV64 is working. I do not have the CV64/3D, but apparently it is also working. From what I have seen for the CV64/3D you need to substitute "virge" for any instance where I mention "cyber". (The frame buffer label "cyber" selects the CyberVision64 driver and "virge" the Cybervision64/3D driver.) I use a simple boot script as follows: copy bootstrap ram:boothack boothack --apus -v -k ram:vmlinux root=/dev/hda3 video=cyber:1024x768-8 Apparently, only resolutions understood by &linux; work at present. Therefore, you should choose 640x480, 800x600, or 1024x768 in the above statement. I believe all of them have been reported to work. I'm sure that there are others, but I haven't done much experimentation at this point. Make sure that before you boot &linapus;, that your CyberGfx video mode matches what you have selected to boot &linapus;. I believe the two key factors in the command line are the -v and video= options. You should be able to modify the rest to suit your configuration. Once you have successfully booted &linux; you will see the penguin drawing and probably a much higher resolution that what you have seen before. To run &x; you will need to specify the resolution in the /etc/XF86Config file. There is an example in the same directory as where you found Geert Uytterhoeven's &x; server. To figure out what parameters you need, use "fbset -x" You will also find fbset in the, by now, famous directory with Geert Uytterhoeven's &x; server. which will show you what you are currently using. If you are running in an interlaced mode, the fbset program will show you values that your monitor will not actually support. BUT... these values will work properly. Simply LIE about the scanrate in your monitor definition in the XF86Config file. It will work. Use the values returned from fbset and you should be able to start X with no problem. I'd like to see this paragraph rewritten - I wouldn't want someone accidently blowing up their monitor. Users, do be careful! -Jesper If I use the same resolution for everything, with only one resolution specified for X everything works great. Good luck! Really... it works! Text by Marco De Vitis You have to start &linux; in the screenmode you want to use, through the "video=amifb:pal-lace" or "video=amifb:ntsc-lace" options on the bootstrap command line; you can then start &x; making it use the current screenmode. If you already followed the instruction about running &x; above, the only thing you need to do is edit your /etc/XF86Config file so that the last section "Screen" only contains one "Display" subsection about the "default" mode: SubSection "Display" Modes "default" EndSubsection You can alternatively use Geert Uytterhoeven's XF86Config.pmac file found at www.cs.kuleuven.ac.be/~geert/bin/XF86Config.pmac.gz decompressing it and copying it in your system as /etc/XF86Config, as it is already set up like that. But you'll probably need to edit it anyway to make it work, changing the line: Device "/dev/adbmouse" to: Device "/dev/mouse" Please note that &x; won't be much usable in 640x400 or even 640x512, and the current (at the time of writing) version of XFree86 doesn't support the "Virtual" option for the "default" mode, but it will do it in the upcoming version 3.3.3, allowing you to have a virtual screen bigger than your actual screensize. Text by Matthias Goerdeler After installing &x; for use with AGA vga-mode (just use the XF86Config found in ) as described earlier I could start &x;, but the monitor just didn't sync. So if your problem is that X does not start, this will probably not help you. I got my monitor to sync after changing the line A to line B in the monitor section of XF86Config: [A] HTimings 640 760 804 916 [B] HTimings 640 750 804 916 It should be pointed out that I do not know how to calculate the correct timing values, it was just 'try and error'. And it is not even sure that this will help you if you run into the same problem as I did. But you could give it a try and report your findings to the linux-apus mailing list. You can also compile many applications yourself as the source code is often freely available. This is likely to be necessary if you want to use an application that is not maintained by either the &rhppc; or &debian; teams, as the application author(s) would probably only supply a precompiled version of the application for the ix86 architecture. Some applications need Linux header files to build. These are normally found in /usr/include in the directories asm and linux. When using &linapus; the header files installed by e.g. &rhppc; should be OK for most applications. However, if you decide to replace the default header files with &linapus; specific header files you must also include the directory /usr/include/asm-m68k which must be either a copy of the linux/include/asm-m68k directory or a link to it. When I get reports of hardware configurations that are known to work with &linapus; I put them in this section. You can match these against your own configuration to get an idea of whether &linapus; will work on your box. Note that things listed here are not necessarily included in the precompiled kernels. In comments are listed the people who reported the information - if you have information about a driver currently not on this list (or conflicting information) please let me know. &cybppc; and &blzppc; boards: A4000/o3o with &cybppc; &cpu604;@150MHz (Jesper Skov). A4000/o4o with &cybppc; &cpu604;@200MHz (Jeffrey W. Davis). A4000/??? with &cybppc; &cpu604;@233MHz (Jens K. Jensen). A1200 with &blzppc; &cpu603;@160MHz (Jouko Pynnonen, Sven Luther). A1200 with &blzppc; &cpu603;@200/210MHz (Michel Dänzer). A1200 with &blzppc; &cpu603;@240MHz (Alan Buxey). A3000T with &cybppc; &cpu604;@233MHz (Francisco Sepulveda). Device Drivers: DISPLAY : AGA display. (Jesper Skov) DISPLAY : CyberVision(/3D). (Sven Ottemann/Jimmy) DISPLAY : Picasso II Clgen. (Francisco Sepulveda) DISPLAY : PM2 (Ilario Nardinocchi) The driver included in the precompiled kernel is an old beta. If you want the up-to-date version get the latest sources from the PM webpage (see ). Don't expect the precompiled version to behave as described on the webpage! FLOPPY : &amiga; floppy disk controller. (Sven Ottemann) IDE : A4000 IDE controller. (Jesper Skov) I/O : &amiga; serial. (Jesper Skov). I/O : &amiga; printer. (Bartek Kozakiewicz) NET : A2065. (Jesper Skov) NET : Ariadne. (Thomas Lohmann) NET : Ariadne II. There's a performance problem with the driver. It runs at 10% of the speed compared with the &ados; driver. (Martin Koenig) NET : Hydra. (Francisco Sepulveda) NET : SurfSquirrel. (Carlos Mayo) SCSI : A3000/T SCSI controller. (Thomas Haller/Arno Griffioen) SCSI : GVP 11 SCSI controller. (Alex Kazik) SCSI : GVP A2000-HC+8 Series II. (Thomas Lohmann) SCSI : Oktagon 2008 SCSI. (Carsten Pluntke) SCSI : A4091/4000T SCSI controller. You have to disable the use of BATs to map main memory. Add "nobats" to your kernel options. There are still some stability problems with this driver under &linapus;. (Ken Tyler) SCSI : Blizzard/PPC SCSI controller. You have to disable the use of BATs to map main memory. Add "nobats" to your kernel options. (Sven Luther) SOUND : &amiga; DMA sound. (Carsten Plunkte) Software Drivers: FS : affs (Jesper Skov). FS : dos (Sven Ottemann). FS : ext2 (Jesper Skov). FS : hfs (Bartek Kozakiewicz). FS : iso9660 (Bartek Kozakiewicz). FS : joliet (Bartek Kozakiewicz). FS : minix (Jesper Skov). FS : proc (Jesper Skov). FS : vfat (Sven Ottemann). MISC : z2ram (Jesper Skov). RAM : ram disk (initrd) (Jesper Skov). PROTOCOLS: PPP (Carsten Pluntke). There are still plenty of problems with &linapus;. Remember it is a developer kernel, so you cannot expect everything (or anything) to be working. It should get better as time goes by, though. The To Do list below is basically the list of known problems. If you have anything to add to the list, or if any of the listed devices are working for you, please let me know. I work on things as my time permits. I have had bad experiences (plural!) with fixing drivers for devices I don't have myself - it takes too much time and energy, even when someone owning such a device offers to run test kernels. Thus, if you want to see a working driver for your hardware, you really need to start hacking yourself. This is a list of jobs that are up for grabs. If you want to do it and you think it will take more than a couple of days, please let me know so I can mark it to prevent duplicated efforts. (free) If the &ados; ROM is shadowed, it will eat 512kB RAM. It might be possible to disable this shadow mapping, but I don't feel like hacking on it myself - it can be disabled manually in the Early Startup Menu. (free) &cpu603; support is not as good as it should be. In arch/ppc/kernel/head.S and arch/ppc/mm/init.c the flag NO_RELOAD_HTAB should be set but this causes the kernel to hang at the moment. Probably some tophys/tovirt oversigt in head.S. ( Roman Zippel) Merging the &amiboot; changes. We need someone to maintain the &amiboot; program as Geert Uytterhoeven does not have the time anymore. Presently I have put the &linapus; required changes in . (free) A4000T/A4091 SCSI drivers require the kernel to be compiled using segment registers for memory mapping. Page translations are cached in on-chip translation lookaside buffers (TLBs). When a memory access is attempted and the page information is not found in the TLBs, a table lookup from main memory is required. When the kernel is mapped with BATs, execution of kernel code does not require looking up information about individual pages as the entire kernel memory space is mapped in one chunk. As the kernel memory space used to hold the NCR53c7xx SCSI scripts needs to be mapped as write-through rather than write-back, per-page cache control is required. The current kernel memory system does not mix BAT mappings with segment register mappings, so kernels compiled after 980820 have to use segment register mappings only to ensure that A4091/A4000T drivers work correctly. Two things can be done about this; in the short term, users who don't use the affected SCSI drivers can rebuild the kernel using BATs for memory mapping (undef MAP_RAM_WITH_SEGREGS in arch/ppc/mm/init.c). A proper long term solution for all users is kernel support for a mixed mapping strategy. Either by mapping the end of kernel space with segment registers and having a special allocator to deal with it, or by re-mapping the required pages with segment registers. The latter strategy is in my opinion better as any overhead will only affect the pages used for the SCSI driver scripts. Unfortunately it will require (minor) driver changes. The former will affect the entire region of memory mapped with segment registers (which will be 1/4 of the available memory - 8-16MB on most systems). I would like to work on this after the machine dependencies have been cleaned up in &linux; 2.3, but I see no reason to spend energy on it in the immediate future (since the drivers are working and users without the SCSI controllers can rebuild a kernel with BAT mappings). Other issues: Complete driver for the &cybppc; onboard wide SCSI controller. Jes Sørensen is working on this. Complete integration in the &linppc; source tree. Recompiling a &linapus; kernel will require special patches for a long time to come. &linapus; relies on files from both the arch/m68k and arch/ppc directories which makes a clean merge with the main source tree problematic at best. There is hope though; since &linapus; is not the only port with this problem (sparc/ultrasparc, mac/powermac) there has been discussions of introducing a new "mach" hierarchy where sources specific to a given machine (such as the &amiga;) can reside. I will continue upgrading the patches to the latest release kernels and work on integrating changes in both arch/m68k and ppc/arch. Jes will probably be doing a lot of editing when it gets to the time of implementing the mach hierarchy. Completing the LILO port. Roman Zippel is working on LILO support for &linapus;. There have been a few suggestions for improving &thisdoc; which require more time than I have at the moment - or I simply don't think it's worth the effort. If you want to write a section please do so in SGML (have a look in faq.sgml to get an idea of what is required). If you can't be bothered to do that, just send plain text and I will set it up in SGML. Do not send me HTML! Again, if you think writing a section will stretch over a couple of days, please let me know so I can fill in your name and prevent wasted effort. (free) A section with boothack example configurations. (suggested by Christophe Decanini) (free) A section with example memory files - I already put in the section but it's empty as no one returned my request for configurations... These might come in handy again since the kernel will eventually support both BAT and SEG mapped memory (since BATs are more efficient). This section should also describe how the memory system works on APUS (shadow mapping, missing 512KB, etc) - this should make it clear why memory files are (well, have) been required. Also how to properly calculate the values of a memory file. There are three "official" ways of reporting problems and getting help. There may exist other news groups or mailing lists dedicated to &cybppc;, &blzppc; and/or &linux;(/APUS) than the ones described in this section. Don't expect any of the developers to read those - reporting problems by any other media than those described in this section is just as likely to be successful as reporting them to your mother (my apologies to any &linapus; hacking mothers out there :) Before reporting a problem, please read the section about etiquette! Mention that you run &linapus; if you are posting a generic &linux; question to the news group. Your problem may be &linapus; specific and you will help other readers realize that if you properly identify the &linux; port you are using. To help others help yourself, always include as much information about the problem as possible. See . Keep your postings in a positive and friendly tone and don't expect the problem to be fixed right away. What is likely to happen is that someone will suggest solutions to your problem: you may be asked to try things you have already attempted (but didn't mention - be very informative!), you may be asked to test special versions of the kernel or the application. It's not guaranteed that your problem will be solved, but with a bit of luck it will be. Above all, be patient, understanding and positive - the developers may be working on other things, helping others with their problems, trying hard to have a life, or simply be clueless about the nature of your problem. Do not send questions like "I cannot boot &linux; on my &amiga;. What's wrong?". You cannot expect anyone to answer such postings, especially because there's no way anyone can be helpful without first making enquiries about your system - save yourself and others the inconvenience: supply as much information as possible. Please don't spam the kernel list or the news group with stories about how poor you think the &linapus; support is, or how the developers lack dedication. The only thing you get out of this is a bad reputation - it doesn't make it easier for us to support devices we don't have. The same goes for failing applications and/or generic kernel problems; if none of the developers are using a particular feature of the kernel or application it is hard to ensure that it is working properly. Again, it's your responsibility to help. Please read existing documentation before posting questions. Even though some helpful person will probably answer a frequently asked question, it's impolite (on your part) to expect others to spend time helping you when you cannot be bothered to take the help people have already offered you in form of FAQs, manuals and previously answered questions. Start by looking in the directory /usr/doc/HOWTO on a &rh; machine which may contain the answers you are looking for. If possible, it's always a good idea to search news group and kernel list archives for a solution to your problem. See the links page (). The Usenet News Group comp.os.linux.m68k is read by many &amiga; users who use &linux;. It's a good place to ask if you have simple questions about &linux; that are specific to the &amiga; (see below for &linapus; questions). You can also ask more generic questions about the use of &linux; even though you would probably be better off posting to groups with more traffic and readers. Remember, &linux; is available on many platforms - an application problem you have is likely also to be a problem for, say, an ix86 (Intel) user. And there are tons of help to be found in FAQs, HOWTOs and general &linux; documentation (see ). If you are new to &linux; you might even consider buying a book about &linux; usage - this is one of the things that sets &linux; apart from &ados;; there are so many users that there's commercial interest in supporting it (with books and hot-line help). If you have a problem that is specific to the &linapus; installation, use of specific &linapus; packages, or if you think you have found a problem with the &linapus; kernel (i.e., a driver problem or a generic kernel problem), you should mail to the &linapus; kernel mailing list. You should describe how to repeat the problem. It's very hard to debug something that cannot be seen. Some problems are periodic or occur at random times in different applications, which is not easy to repeat. In this case, include whatever information you have in the posting. You can follow the traffic on the kernel list via the news gateway at news://sunsite.auc.dk/sunsite.linux.apus. It's fast and your mail box is not overburdened. You can also join the list (send mail to linux-apus-help@sunsite.auc.dk). You can post to the list at the address linux-apus@sunsite.auc.dk. This is not the place to ask for help. This address's usage should be restricted to sending the maintainer FAQ submissions. Everything else should be posted to the kernel list which has a wider audience. At the &linm68k; domain &linapus; has kindly been given an email alias apus@linux-m68k.org. This will forward mails to whoever is maintaining &thisdoc; (at the moment me, Jesper Skov). In this chapter you will find a list of frequently asked questions. If you don't find the answer to your question, please read . How come my questions are not answered? Perhaps nobody knows the answer, or the question is not directly related to &linapus;. If the same problem is reproducible under &linm68k; you would be better of asking in a &linm68k; forum. If you don't experience the problem under &linm68k; it is likely to be &linapus; specific; please include this information when you post to the &linapus; kernel list. Even though this doesn't improve the chances of getting the problem fixed, the problem can be mentioned in &thisdoc; so others will be aware of it. Your question could already be answered somewhere in &thisdoc; and nobody can be bothered to tell you this. Help yourself; read the entire document - it is not that big. It is also a good idea to search for the answer to your question in the &linapus; kernel list archive. If you find answers to your questions in unexpected parts of this document or in the kernel list archive, please let me know so I can update &thisdoc; for the benefit of the next user with the same problem. Are there any &ados; requirements? Yes. Even though the &linux; kernel in itself does not use &ados;, booting the kernel relies on &p5;'s &cpuppc; micro kernel. Is &linapus; binary compatible with the other &cpuppc; &linux; ports? Yes. You can (AFAIK) use most software packages precompiled for &linppc;. Some noteworthy exceptions are: the X server (see below) and &amiga; or &linapus; specific tools which you are not likely to find available from normal &linppc; sites. How come not all &linm68k; supported devices can be selected when configuring? Because &linux; configuring at the moment is architecture dependent. You have to move items from arch/m68k/config.in into arch/ppc/config.in or (even better) into the Config.in in a driver directory. If you do, please post the diff on the kernel list. Are &cybppc; developer boards supported? Not at the moment - and they are not likely to be supported any time soon; moving the &cpum68k; CPU from one board to another is hell and I hate fiddling with the guts of my box. But if you have such a beast, by all means, start porting - I can give you some pointers. Is Netscape available? Yes. And it's even working (according to Jens Kristian Jensen). Is the &cpum68k; CPU used for anything? No. It is put to sleep (stop #2700) during boot. This may change sometime in the future. I guess it could be used as a gfx coprocessor, for clearing empty pages, or even for running native &cpum68k; programs under special conditions (like AROS). Will it ever be possible to use a mixed set of &cpum68k; and &cpuppc; executables? Not likely. This would require a shared memory mapping. However, nothing is impossible - you go ahead! I can't boot from the ram disk with 2.1.90 kernels!?! There's some problem with identifying MINIX headers in 2.1.90. Use gzip to compress the ram disk and it will work. Does &linapus; support kernel debugging with &gdb;? The kernel diff contains the necessary stubs and config flag (CONFIG_KGDB) to do this (originally for PMAC, written by Mike Tesch). A debug kernel is around 10MB though so I will not upload a precompiled kernel with debugging. I have still not tested this so your mileage may vary. When I recompile the kernel using your patches, I get disk failures and runtime errors!?! Use binutils-2.9.1 and egcs-1.1. Get the 980525 kernel sources or newer and you should be OK. Why not use LPSTOP to halt the CPU on &cpu060; systems? It hangs the system. Possibly because the &cybppc; bus design cannot cope with the signals the &cpu060; sends out before powering down. I cannot mount all my partitions. There are not enough dev nodes in the ram disk!?! I have put mknod compiled for &cpuppc; in . Put it on an &ados; partition you can mount, boot the kernel, mount the &ados; partition, use mknod to make new nodes. My system just hangs when I start &boothack;!?? It might be a problem with &boothack;. Try rebooting the machine and run the tool bootmesg. It should find a progress string from the booter. This string is deleted by the kernel if it boots, so if the string is not found, it's probably a kernel problem (and you should use debug=mem and &dmesg; instead). The last character stored before jumping to the kernel is 'K'. If you see a string, and the last letter is not 'K', you can look in the ppc_boot.c code to get an idea of where things go wrong. Please also report your findings. Another thing that is likely to cause this problem is memory. See for some more information on this point. Yet another common cause is wrong video mode parameters. 'vga' has caused problems, while specifying none (if your monitor can handle it) definitely works. If you have a CyberVision you have to let it be initialized by CyberGfx before you boot. You must also disable Shadow ROM in the &cybppc; or &blzppc; Early Startup Menu and set the memory speed to 70ns. Finally, make sure to put &boothack; options (starts with a dash (-)) first on the line and kernel options (no dash) last on the line when booting the kernel. Can I boot from a soft kicked system? Possibly. You might be able to make it work. Do try it. If it doesn't work you have to disable the soft kicked ROM. You might also try booting your machine without startup-sequence, run setpatch and then start &linapus; (unless you have a CyberVision in which case you must let CyberGfx initialize it first). Can I compile my own kernels under &linapus;? Yes. I have successfully run a kernel I build with binutils-2.9.1 and egcs-1.1 on my &linapus; box. However, YMMV. I get rejects when applying your patch!!?? My patches are relative to the release versions of the &linm68k; kernel sources (not Linus' kernel sources!). If you apply &linm68k; patches from the &linm68k; kernel list before you apply my patches, you may get conflicts. I cannot boot &linapus; on my &blzppc;!!? Hint from Sinan Gurkan The later firmware versions make the hardware identify itself as if it had a SCSI controller - even the boards with no SCSI controller! Until the problem gets properly fixed, you can press s during boot to disable the (non-existing) SCSI hardware :) How do I boot with AGA display on a machine with CyberVision(/3D)? You need to disable the frame buffer device assigned to the graphics card by adding (one of) the below to the boot options. video=cyber:off video=virge:off How do I change the default keymap? Text by Marco De Vitis Let's assume you already have a keymap file that suits your system, e.g. amiga-it.map for an Italian Amiga keyboard (you can find many keymap files at ftp.uni-erlangen.de/pub/Linux/680x0/bin/system/keymaps/). Put this file in the /usr/lib/kbd/keytables directory. You should now be able to load it by issuing this command: loadkeys amiga-it.map To have it loaded during boot (on &rhppc;), you have to edit the /etc/sysconfig/keyboard file so that it contains the full path to your keymap; by default, it should read something like "/usr/lib/kbd/keytables/amiga-us.map", so you usually only need to change the ending. How come the sound driver is not included in the prebuilt kernels? Because it doesn't like the heartbeat (which affects the filter when blinking the led). Heartbeat is important for determining if &linapus; has properly booted even if the display is blank, i.e., it is relevant in a kernel that a novice will boot for the first time. And it means I don't have to switch display each time I boot a kernel ;) If you worry about sound support, it means you have a stable system -- and that means that you should be able to rebuild the kernel yourself. Why can't the mailing list...? It's not by accident that the list server is set up as it is -- this is the way the guys in power like it :) See below for some workarounds. SUBJECT LINE: If you want [APUS] or similar in the subject line, it's probably because you want to sort/filter your mail by subject. In that case, your mailer should be able to sort/filter by any other header line. A good one is: Mailing-List: contact linux-apus-help@sunsite.auc.dk; run by ezmlm REPLY-TO: Yes, you 'reply' to the author of the article. We are all real living people -- if you want to reply to something it's because you want to say something to the dude at the other end of the damp string, no? :) Polite people mostly CC: the list so others can benefit from the reply as well. So, use 'followup' instead of 'reply'. Yes, the receiver gets two copies; that is The-Way-It-Should-Be(TM). I like to follow the progress of the stuff I use, so I decided to keep track of &linapus; changes so others with the same interest can get an idea of what's happening. I also try to keep a source code ChangeLog for the &linapus; changes which is available from . date990322 990322 Added mb() fix for A2091 driver from Jes. date990321 990321 Added yet another info item for GPM, this time from Gerard Cornu. ChangeLog now available from this document. Incremental change logs included in the linux-apus-YYMMDD.diff diffs as a comment. 990301 Ken Tyler sends me a virge blitter fix as a birthday present ;) 990221 Arno Griffioen takes matters in his own hands and fixes DMA on the A3000 SCSI controller :) I added the same DMA patches to the A2091 and GVP11 drivers. 990220 Updated to &linm68k; 2.2.1pre2. Cleaned up serial driver and GDB support. 990214 Added gpm note from Robert Ramiega. 990206 Updated to &linm68k; 2.2.1pre1. Removed parallel/printer drivers. The new driver scheme seems to hang the kernel and I don't have the time to track it down now. 990203 Updated &thisdoc; to compile with DocBook 3.0 990201 Debian install help updated (Michel Dänzer) Added Virge Z2 support from (Christian T. Steigies). 990131 NO_RELOAD_TAB fix from Michel Dänzer. Cleaned up APUS: output during boot. 990129 Virge update from Ken Tyler. Other video updates from Geert Uytterhoeven. 990123 Module fix from Andreas Schwab. Menuconfig and module fix from Michel Dänzer). Rewrote part of the interrupt handling. Lvl7 interrupts cannot be avoided, but they are now treated as the bogus Lvl0 interrupts. 990118 Updated to &linm68k; 2.2.0pre7. Replaced the obsolete cvppc driver with the pm2 driver (Ilario Nardinocchi). Fix BlizzardPPC SCSI's dependencies (Michel Dänzer). Replaced iobarrier() with mb(). 990113 Added fix for building lp as module from Frank Petzold. Removed FastLane from list of working hardware and from the precompiled kernels. 990112 Added &debian; installation section by Michel Dänzer. 990111 Updated to &linm68k; 2.2.0pre6. There might be problems with memory mapping devices. If you experience problems, try using the nobats option. 990106 Added PowerUp PCI Bridge detection to boothack. Contributed by Ralph Schmidt. 990105 Updated to &linm68k; 2.2.0pre4. Light my fire, baby! It's smoooking fast :@) &x; starts in no time now... I need to get this kernel installed on Concubine! Changed installer directory structure on &sunsite; in preparation for proper support of &debian; installation schemes. Martin Koenig sez the Ariadne II driver is working (somewhat slow though). Carlos Mayo sez the SurfSquirrel is working. (PCMCIA card, right?). Updated &thisdoc; here and there. If I missed anything during the past couple of weeks, please let me know. 981216 Updated to &linm68k; 2.1.131. 981213 Added patch from Richard Hirst to fix CDROM mount problem on A4000T/A4091 SCSI. Changed CONFIG_PPC in sound driver to CONFIG_PMAC. I'd like to know if it solves the problems. 981129 Added a handful of patches from Chris Lawrence. 981127 Updated to 2.1.130 Fixed off-by-1 error in reloc code. This is what stopped some people from running the later kernels, I'm sure. Added a (good) handful of iobarriers to the MFC serial driver. It might have fixed the reported problem. 981126 The latest directory now contains files (not links) with dated names to prevent confusion in the future. If people try to download using a cached and obsolete name, they should get an error. Reintroduced the head.S progress values. 981125 Included Whippet driver. I got a patch from Carlos Mayo some time ago, but it was already included in 2.1.127. Changed a few bits of the new relocation magic per suggestion from Paul Mackerras. I can't imagine it will help on the failing boxes but one never knows. Added new sections by Marco (FAQ) and Matthias (X). 981122 Added some &debppc; links from Sven Luther Updated list of included drivers. The vger integration is pretty much done now. Reports of 981121 failing to boot. *sigh* If you can get it to boot, use an older kernel. 981121 Added X help text from Marco De Vitis. Good progress on the major &linapus; workover and vger integration. It's now close to being possible to boot a &linapus; kernel on any of the other PPC targets. Do I need to point out that this is a Good Thing(TM) for distributions? :) Still a few nits to sort out though. &boothack; needed a modification to allow the above changes so you need to get that as well. It is backwards compatible, so you can still use it with the older kernels. Included pretty much all drivers in the kernel image (and Mac FS and partition table support). 981117 Worked on vger integration. 981114 Renamed iobarrier macros. Updated CyberVision driver. Might have broken it, please let me know. Cleaned up links (see ). 981112 Replaced auxmem with a simpler hack. Even though auxmem would have been pretty compared with the random hacking of Z2 and motherboard memory now used, it would also have been overkill. Updated to 2.1.127. 981108 Added section about installing from a &rhrc; CD. Included Ilario's CVPPC frame buffer device. See the home page for details on use (). 981107 Sync'd with vger again. Mainly to get some &linapus; changes into the &linux; main tree. Juiced up my motivation (nice meeting you, Ken & Julian :) Fixed stupid bug in mm_ptov. Found by Ilario. Redid the fb X fix, avoiding ptov calls. 981105 Added '60nsram' kernel option. Added 'nobats' kernel option. Improved memory mapping; should use BATs correctly, even on &blzppc; cards with weird alignment. 981103 Added patch from Peter McGavin to fix EGS. Added patch from Frank Petzold to fix modules. Worked a bit more on &thisdoc; 981102 Sync'd PPC stuff with vger. Proper fix to the X problem. Started rearranging &thisdoc; into two parts. 981031 Added IDEDOUBLER fix from Geert Uytterhoeven. Added X fix from Carsten. Added some installer doc changes from Ken Tyler. 981018 Sven found the problem preventing proper operation on Blizzard. It was as suspected all along related to the new (soon obsolete :) booting process. I have started using egcs-1.1 for building kernels. They seem to work fine on my box. I'd like to hear from you ASAP if they don't work on your box. I don't know if the patches are necessary for egcs-1.1. I guess time will tell. (Remember; if parts of the patch seems to be missing in egcs-1.1 it doesn't necessary mean that the problem the patch fixed in 1.0.3 hasn't been fixed in some other way.) Included the serial driver again. 981014 Added &rh; install updates from Ken Tyler to &thisdoc; 981009 Updated to 2.1.124 (X is still broken). 981005 Included Fastlane SCSI driver. 981004 Wasted some more time on KGDB. It's still not good, but it's better. Added heartbeat. 981003 Made KGDB work (still some problems to sort out, but it is usable). Added workaround for ioremap bug. You can now use motherboard/Z2 memory for swap (see relevant FAQ entry). Added compiler option (-fno-strength-reduce) that may (or may not) affect the A4000T/A4091 SCSI drivers. 981002 Added some more changes to the &rh; installer sections from Ken Tyler. 980926 Included some changes to the &rh; installer sections from Ken Tyler. Added new FAQ entry from Ken Tyler (disabling CV to boot on AGA). Added new section with suggestions for &thisdoc; Christophe Decanini reports that RH CDROM, FTP and NFS installation methods work. 980915 Added Geert Uytterhoeven's patch to allow 1024x768-16bp with CyberVision. 980912 Undid the first change of 980907 since it made the kernel fail to boot on most other machines. 980908 Updated to 2.1.120. 980907 Only 128kB is eaten by the PPC exception registers now, leaving 384kB more free memory than before. Added a simple and not yet fully functional method for using motherboard memory as swap. See new FAQ entry. 980902 Submitted patch to vger (well, to Geert, really :) Added code to determine bus speed written by Ralph Schmidt. 980901 Added latest vger PPC changes. The above bloated the kernel so much that a linker/booter problem prevented it from booting. I removed the Retina and clGen graphics drivers because of this. 980831 It's now possible to disable wait states for all bus speeds. Sven Ottemann has been pushing for this for some time, but let me warn you; you need 60ns RAM, and according to Phase5 it doesn't work on 66MHz buses. YMMV. Now the bus speed ID is output at startup to help debugging. 980830 Sven Ottemann fixed the booter to be a one-file image, rather than the old ADOSHUNK/ELF pair. Made the booter clear all MMU registers. head.S now sets up all the required mappings - which makes the &blzppc; get past the old trouble spot. There are still some problems left though. Reintroduced colors to &thisdoc;, marking new stuff. The chapters and sections are appended with a date where appropriate so you can see where the latest changes are from the table of contents. 980829 Updated to &linux; 2.1.119. 980827 Fixed a potential problem in head.S. &blzppc; owners should give it a try. 980822 Ken Tyler informs me that the A4091/A4000T SCSI driver is finally working. This is due to the fabulous work of Richard Hirst. Still, this has resulted in an item on the to do list (performance penalty). I have put my sources under CVS control so in the future I will be able to release incremental diffs of the &linapus; sources. 980821 Francisco also reports that the Hydra driver is working. &blzppc; owners should check the FAQ entry specific to their HW. I just added a suggestion from Sven Luther. 980820 Francisco Sepulveda informs me that the Picasso driver is working on his A3000T. Added patch to menubox.c from Frank Petzold. Changed kernel to use segment registers for mapping kernel space. This might fix the A4000T/A4091 driver problem (even though I'm tired of being enthusiastic about that :) 980816 Completed move of &thisdoc; to DocBook. That took some time! I wonder if anyone will miss the color highlighting of changes to the document? If so, let me know and I will get it working again. Added some changes from &linppc; 980813 Included &blzppc; SCSI driver again. Included Buddha IDE driver. Included patch to socket.h 980812 Included clgen gfx driver. More additions to the A4091 support. Updated to linux-2.1.115 980801 Unfortunately the new &boothack; still can't boot &linapus; properly on &blzppc; - possibly a problem with the 040. I'd like to hear from &cybppc; people who can boot on an 040. Added a few syncs and eieios to the booter. Added Sven's Blizzard SCSI patches. The kernel image in vmbl980801.lzh includes this driver and a not the Gayle IDE driver which conflicts with the SCSI driver for some reason. 980730 &boothack;: Added more robust synchronization between the CPUs (the "wedgie" scheme). &boothack;: Added stack space for &cpuppc; in CHIP. &boothack;: Invalidate cache contents. &boothack;: Disable TimerBase interrupts (this is the one that won the gold). The above ensures rock-stable booting on my box with the 980711 ppc.library. No more bad checksums; it's just awesome :) 980726-2 Updated my ppc.library to 980711. I now know what the problem has been on the &blzppc; cards - I think :) Moved head.S progress word to 0xfff0eff0. Added some text about how to avoid memory problems when booting (Please do read it and tell me if it is of any help, or if it requires changes/additions). Added checksum code to the booter. 980726 Fixed the problem with zorro devices count. Fixed memory initialization code again. 980725 Fixed silly bug in an A4091/A4000T SCSI driver support routine which caused kernel panics. Thomas Lohmann informs me that Ken&Son's &rhinstaller; works with FTP. Added new contrib directory at &sunsite; (see ). Memory initialization should now correctly identify an active &ados; ROM shadow and ignore that 512kB block of memory. 980724 Changed date format to YYMMDD. Fixed problem with Zorro structures (get newest &boothack;). 980723 Apparently lots of stuff is broken in 2.1.108: CyberVision, GVP HC+8, you name it. I'm clueless. Nothing really changed on the &linapus; side of things, so I must have missed some serious &linm68k; changes. Thomas Lohmann informs me that CV works with the console in all resolutions after he installed the ppc.library included in cybergfx of 05.07.98 (IIRC). I tried including sound in the kernel, but there is a build problem. I have made some changes to the A4091/A4000T driver support that might make a difference. 980719 Added Richard Hirst's 53c710 patch. 980711 Moved patches to 2.1.108. Added a few FAQ changes suggested by Thomas Lohmann. He also told me that the GVP A2000-HC+8 Series II SCSI controller is working with &linapus;. 980710 Increased SCSI timeouts. Tested &linapus; startup with ppc.library version 46.15 and 68060.library version 44.3. No problems whatsoever on my box. 980707 Massimo Gais has made a mirror of the apus directory at ftp.unina.it. 980617 Reordered the sections in the installation chapter. Changed the booter to disable ROM mappings. Maybe it will help on &blzppc; cards? 980616 I have run of ideas for what could be causing the &blzppc; problem. Someone with a &blzppc;s needs to dig in and have a look. I'm not spending any more time on this.... Ken and Julian Tyler have completed the &rhinstaller; support for &linapus;. Obviously this makes it much easier to get a system properly installed and working. 980615 &sunsite; has been unaccessible for a couple of days now. It's due to a cut cable on the Danish back bone (I think). Bartek Kozakiewicz tells me that HFS and ISO9660/Joliet drivers are working. And also that the printer driver is working. 980612 Now writes head.S progress to 0xfff07000. Hope it works this time... *sigh* Cleaned up &linapus; changes to intrude less on the &linm68k; sources. 980610 Carsten Plunkte tells me it is important to apply the egcs patches from &sunsite; if building applications (I added a new subsection to Applications). 980609 Moved patches to 2.1.105. Geert Uytterhoeven tells me that emacs-nox also fails on CHRP so it is indeed an application problem. 980607 Updated ppc.library to V45.20. Everything is still working. Also tried installing another 8MB but the ppc.library (V44.27) wouldn't run then. I might try installing the RAM again with the new ppc.library at some time. Corrected initial mapping in head.S - I had set it to 4MB, not 8MB. Now writes head.S progress to address 0xfff02ffc which exists on all PoweUp boards and is not deleted by the &p5; &cpuppc; software (not on my box anyway). 980606 The emacs compiled with X libs works, so I think the problem with emacs-nox is probably a generic (application) problem, and not caused in particular by the &linapus; kernel. More reports of problems booting the newest kernels. I'm at a loss here - the kernels are working fine on my box. 980604 Merged in a few vger changes and submitted the few &linapus; changes to the vger tree. 980603 I replaced the head.S serial progress output with a counter updated in memory. If the kernel hangs for you before it opens a display, have a look at address 0xfff04000 after rebooting. The long word should read 0x1234000?, with ? being between 1 and 8. 980601 SCSI drivers are now again included in the precompiled kernels. 980528 Exception registers are now mapped with caching enabled. The kernel can now reboot the machine (thanks to Holger Jakob who bugged Ralph Schmidt for the information.) The kernel should now be able to handle weird aligned memory (such as 24MB aligned to an 8MB boundary). While working its way through head.S (early initialization) the kernel now writes the characters A-F to the serial port much like &linm68k;. Caching issues prevents it from being just as detailed as in &linm68k; though. Removed BOOTP/RARP support. 980527 Found potential cause of the &blzppc; problems; the first mapping set up before the memory system is initialized used a 64MB mapping instead of the 16MB mentioned in the comment. I changed it to 8MB which should allow a &blzppc; box with only 8MB to boot &linapus;. Included support for msdos partition tables. Put some patches for egcs-1.0.3 in the misc directory at &sunsite;. I don't know how important they are: I've recompiled a working kernel under &linapus; without the patches. The patches are from a posting on the &linppc; kernel list. 980525 More patches for vger and the &linm68k; kernel have been submitted. &linapus; is now up-to-date with &linm68k; 2.1.101 and &linppc;-vger-980523. I finally got around to installing a new disk in my &amiga; so I can now do some more testing on it. Also installed &rhppc;/1998. Egcs-1.0.3 has been released. There are still some &linppc;-specific patches which have not been included, but with egcs-1.0.3 and binutils-2.9.1 I can compile a working kernel under &linapus;. 980521 Added a new section with mirror sites. First entry is in Poland (thanks Bartek). If you have made a mirror or an archive of the mailing list please let me know. Jimmy "What's-yer-sir-name?" reported that X is finally running on CyberVision. Shortly after Jeffrey W. Davis posted a nice HOWTO on the &linapus; kernel list which I have put in the FAQ section. Most of the remaining &linapus; patches have been applied to the &cpuppc; tree at vger. 980516 I added a new section about kernel debugging. I completed the &linm68k;-2.1.99 and vger-980424 merge. I'll upload this diff and start working on merging 2.1.1xx and vger-980514. Sven Ottemann reports that CyberVision is working with the console. X does not work. (old news btw, but now it's in the list). 980514 Alex Kazik reports that 980507 change fixed the problems with the GVP 11 SCSI driver. 980512 The 980507 change did solve the problem with at least A3000 SCSI. The 53c7xx driver (A4000T+A4091) is also broken under &linm68k; so it will not be fixed by the change. I got my vger merge booting as far as INIT. I'll merge it with 2.1.99 before tracking the last problems down. Removed A4091 and A4000T SCSI drivers from the precompiled kernel. 980507 Hopefully fixed kernel_map/VTOP problems. Also cleaned up cache functions. SCSI users should try if this improves things. 980506 Removed the sound driver from the precompiled kernel. 980503 Completed vger merge. Can't test it though since my shiny new &rh; 5.0 box doesn't like me using the network. I'll re-install 4.2 sometime in the coming week. I think I have found the problem with the SCSI drivers: they use cache_flush/clear with addresses that are not necessarily in kernel space (bounce buffers. user space buffers(?)). The &cpuppc; uses virtual addresses in its cache instructions and PTOV is non-trivial, slow and definitely not working correctly at the moment. Have to give this some serious thought. 980502 Thomas Lohmann reports that Ariadne is working. Updated texts about news group and cross-compilation. 980501 Jouko Pynnonen reports that &linapus; is finally working on the A1200 &blzppc;. Sven Ottemann updated the hdinstall script. Holger Jakob uploaded an XF86Config example file for 640x480x256 AGA, and a patch for gpm. 980429 Tripled SCSI timeouts. Reverted BAT mapping change of 980425. Configurations with non-power-of-two memory sizes fail with this. I have to rewrite the memory mapping to support the &cybppc; HW properly: the &cpuppc; is not happy with the weird alignments caused by growing the memory downwards (as designed by &p5;). If &ados; was using the MMU, I'm sure the memory base would be at the bottom of the addressing space. Changed the CPU speeds for &blzppc; to 50MHz/66MHz. Continue with vger merging. 980428 Started to merge the latest vger changes into the &linapus; kernel sources. 980427 Use same page fault mechanism on &cpu603; as on &cpu604;. May solve problem with &blzppc;. Realized that some people might have a memory configuration which cannot be mapped with BATs. Added instructions in . The kernel I build with egcs-1.0.2 after disabling the inline assembly versions of __swab16/32 seems pretty stable. 980426 Made a small (fancy :) script which makes it easy to mark changes in the HTML version of this document with colors. Had a go at using egcs to compile the kernel. Didn't work very well. I hope the next egcs release will fix it. If you have the time, please try to get gcc-2.7.2.1 (available from &sunsite; in misc) running under &linapus; and upload the binaries to &sunsite;. Sven Ottemann reports that the floppy driver works with both affs and msdos formatted floppies. 980425 Map exception vectors and &cybppc; control vectors with different BATs for improved performance. Unfortunately the last booter changes made it unusable. The 980425 version should be better. 980424 Thomas Haller reports that A3000 SCSI actually works if DMA is disabled. Added some progress information to the booter which can be used (hopefully) to find the &blzppc; problems. See FAQ. 980423 Fiddled a bit with gcc under &linapus;. The version of gcc I use on Concubine (x86) I cannot get properly working under &linapus;. I have to look into the problems with egcs RSN. I put an additional gcc patch on &sunsite;/misc, but it's probably not worth getting; &linppc; is going to use egcs in the future so I have to get those problems fixed anyways. Stay tuned! 980422 Fixed bus_to_virt/virt_to_bus macros. May help A4000T and A4091 drivers. 980421 Checked if LPSTOP could be used on the &cpu060; to reduce heat in the box. It cannot. Fixed problem with debug=mem. This may also affect drivers using the VTOP macro. 980420 Completed the last part of the FAQ. Added the new kernel mailing list address. 980419 Proper bus speed check for A1200 &blzppc;. The new HTML FAQ almost done. Will announce it and the new directory Monday. 980418 Added patch from Holger Jakob to allow inclusion of DMA sound. 980417 Started work on SGML'ogrifing the FAQ. Got a dedicated directory at &sunsite;. Thanks Karsten! 980416 Added a patch from Carsten Pluntke to fix a virtual-to-physical address translation problem causing X to crash. Fixed a potential problem with ioremap. Hopefully SCSI drivers using kernel_map (A4000T/A4091/Fastlane) will now work. 980414 Added a &gdb; debugging stub to the kernel sources (not the binaries). Sven Ottemann completed the HD install script. Get hdinstall.lha and the newest FAQ for instructions. Added handling for booting on systems where the ROM has been mapped to RAM. (not tested) Added a compiled version of the kernel without the A3000 SCSI driver. Added PPP driver. 980409 Added a few extra drivers. 980331 Applied some more of Roman's patches. Fixed RAM disk problem. 980326 Applied a few of Roman's patches. Changed the way the exception vectors are handled. You have to get the new &boothack; as well (bh980326.lha). 980324 Moved the patches to 2.1.90. I still have a few of Roman Zippel's patches that have not been applied. 980316 I wrote a small &linapus; FAQ available from &sunsite; in the apus directory. 980224 The kernel now auto detects the bus speed. If you have a system with a 60MHz bus speed and press the left mouse button while booting, the memory waitstate will be removed (this requires 60ns RAM). 980223 Kernels now compiled for 60MHz and 66MHz busses. Includes a few more drivers. 980216 Kernel seems to be working. I experienced some random signals to user processes during the weekend, but was not able to reproduce it. Compiled a version for 50MHz busses with 60ns RAM. Included System.map and .config for reference. 980212 Did some more magic with the interrupt handling. Tracked down the problem causing the kernel to hang from time to time (A2065). Compiled two versions of the kernel; one for 50MHz bus and one for 66MHz bus. I will add auto detect soon. 980208 Moved my changes to 2.1.85. Cleaned up the handling of interrupts. Mismatch between &p5; doc and actual behavior (&p5; notified). The kernel still hangs from time to time (while processing bottom half interrupt handlers). This might be due to some spurious interrupts, improper interrupt handling, or some problem in the kernel code that only affects &linapus;. I'm looking into it. 980205 Added minix support to the kernel. The kernel happily boots the ram disk but is pretty unstable. This is due to improper interrupt handling. I think I have it nailed down, though. 980204 Ram disks now work properly (also updated the booter). 980203 The patched instructions in the hashing algorithm had to be copied to 0xfff00000 where the exception vectors are located on &linapus;. 980202 IDE driver is now working. Kernel hangs when elf_create_table is accessing the stack of the user program to be launched (problem with exception handlers?) Here is a list of the people who helped make &linapus; what it is today. There is also room for your name! &p5; supported the port of &linux; to their &cybppc; hardware by disclosing information about the hardware to: Roman Zippel ( zippel@fh-brandenburg.de) Jes Sørensen ( Jes.Sorensen@cern.ch) Jesper Skov ( jskov@cygnus.co.uk) A few people have started helping with &linapus;. I hope more will join (see ). If you were not critically deprived of air at birth, and thus do not see the fun in kernel hacking, you can still help. Complement or add sections to &thisdoc;, get responsibility for &debian; or &rh; packages of tools you like, write a helping text for others about a problem you have fought your way through, be helpful on the news group (this would be very appreciated - I can only read news at work and don't always have the time to be helpful myself), send me (or others) grateful emails, or even tons of money. Use your imagination and help make &linm68k; and &linapus; better systems for people with less experience than yourself. There are two parties in particular that I feel deserve kudos: &p5; for helping this port along, and the system administrators at &sunsite; (Karsten Thygesen in particular) for supplying disk space and generally for being a nice bunch (as all Danes are, of course :). For paragraph-sized contributions to &thisdoc;, I put the author's name above the text. Patches to the kernel are rewarded with gratitude and (for bigger stuff) a short mention below. I don't think I want to spend time keeping this part of the document up to date though, so I won't be mentioning every little change. What I will do is to include your name when describing changes in and make a big'ol' list below with email addresses of contributors (big'n'small). If you feel I have forgotten you, remind me by sending an email (and tons of money). Gerard Cornu( gcornu@dtr.fr) ( kcci1@central.susx.ac.uk) Jeffrey W. Davis ( doctorj@netusa1.net) Christophe Decanini ( cdecanini@yahoo.com) Marco De Vitis ( marco.dvv@flashnet.it) Michel Dänzer ( michdaen@iiic.ethz.ch) Massimo Gais ( ftpadmin@ftp.unina.it) Matthias Goerdeler ( goerdler@hp1.imm.rwth-aachen.de) Arno Griffioen ( arno@usn.nl) Sinan Gurkan ( sgurkan@artemis.efes.net) Thomas Haller ( Thomas-h8t.Haller@ubs.ch) Holger Jakob ( jakob@ph-cip.Uni-Koeln.DE) Jens Kristian Jensen ( judas@cs.auc.dk) Jimmy ( Jimmy@Stud-Mailer.Uni-Marburg.DE) Alex Kazik ( martin.koenig@gmx.net) Martin Koenig( alx@gmx.de) Bartek Kozakiewicz ( coza@snickers.ek.univ.gda.pl) Chris Lawrence ( quango@watervalley.net) Thomas Lohmann ( tlohmann@scobs.de) Sven Luther ( luther@dpt-info.u-strasbg.fr) SCSI support for Blizzard controllers. Peter McGavin ( P.McGavin@irl.cri.nz) Carlos Mayo ( COMPMAY@teleline.es) Ilario Nardinocchi ( nardicon@cs.unibo.it) CVPPC driver. Sven Ottemann ( Sven.Ottemann@Student.Uni-Magdeburg.DE) Hard disk install script for the &rh; base system. Frank Petzold ( fpetzold@hepe.com) Carsten Pluntke ( su0289@sx2.hrz.uni-dortmund.de) Fixed vm problem with X. Jouko Pynnonen ( pynjo@jytol.fi) Robert Ramiega ( robert@plukwa.pdi.net) Francisco Sepulveda ( Francisco.Sepulveda@ico.unil.ch) Christian T. Steigies ( steigies@physik.uni-kiel.de) Ken (& Julian) Tyler ( kent@werple.net.au) Fixed the &rhinstaller; scripts to work with &linapus;. Geert Uytterhoeven ( Geert.Uytterhoeven@cs.kuleuven.ac.be) X server binaries. &rhppc; base system archive and installation help. Santa's little vger helper :) If you have any contributions to &linapus; (code, ideas, changes to &thisdoc;, whatever) please send them to the &linapus; kernel mailing list. Archives and/or packages can be uploaded to (remember to notify me via mail). If you have an idea for additional (&linapus; relevant) links, please let me know. &linapus; HTTP Location FTP Location &linapus; Master Site sunsite.auc.dk:/local/os/linux/apus sunsite.auc.dk:/local/os/linux/apus &linapus; Poland Mirror snickers.ek.univ.gda.pl/pub/apus &linapus; Italian Mirror ftp.unina.it &linm68k; HTTP Location FTP Location &linm68k; Kernel Master Site sunsite.auc.dk:/local/os/linux/680x0 sunsite.auc.dk:/local/os/linux/680x0 &linm68k; Home Page www.linux-m68k.org Permedia2 (CyberVision/PPC) Frame Buffer Home Page http://www.cs.unibo.it/~nardinoc/pm2fb/ &linppc; HTTP Location FTP Location &linppc; Master Site www.linuxppc.org ftp.linuxppc.org &debppc; HTTP Location FTP Location The &debppc; port www.debian.org/ports/powerpc/ &debppc; packages ftp.debian.org/debian/dist/main/binary-powerpc/ &debppc; install stuff ftp.debian.org/debian/dists/sid/main/disks-powerpc/2.0.11.4_1998-10-15/ &linux; Help HTTP Location Comment News Archive www.dejanews.com Search for keywords, include "linux" WEB Search www.altavista.com Search for keywords, include "linux" MiningCo linux.miningco.com Search for keywords &linux; Kernel Hacking HTTP Location Comment &linux; Kernel (Hacking) FAQ www.tux.org/lkml/ Software HTTP Location FTP Location binutils prep.ai.mit.edu, sunsite.auc.dk/mirrors/prep.ai.mit.edu/pub/gnu/ egcs egcs.cygnus.com egcs.cygnus.com, sunsite.auc.dk/mirrors/egcs.cygnus.com Mozilla www.mozilla.org ftp.mozilla.org &rhppc; www.linuxppc.org ftp.linuxppc.org X www.cs.kuleuven.ac.be/~geert/bin/XF68_FBDev-ppc-19981017.gz &p5; www.phase5.de. &sunsite; is the main distribution site for both the &linm68k; and &linapus; kernels (no, it's not a coincidence: both Jes and I studied at Aalborg University). There's lots of other good stuff there, and it's well worth a visit. You can access it by both HTTP and FTP (using the same hostname and paths). You can find &linm68k; related stuff (including the &linm68k; FAQ) in the directory sunsite.auc.dk/local/os/linux/680x0/. The &linapus; directory is sunsite.auc.dk/local/os/linux/apus/. This directory contains the following (and possibly more; have a look around): DEB-APUS Directory with &debian; packages recompiled especially for &linapus;. I need your help to get it filled with good stuff! RPM-APUS Directory with &rh; packages recompiled especially for &linapus;. I need your help to get it filled with good stuff! boothack Directory with the special version of &amiboot; required to boot a &linapus; kernel. contrib Directory where I put kernel images and diffs contributed by users. If you want to contribute, upload to incoming and notify me via mail I only accept uploads with an accompanying .readme file containing: Uploader: Name and email address. Contents: Archive description and/or a description of why people should use it. Also, please make sure to notify me when an archive becomes obsolete so it can be deleted. . docs Directory with &thisdoc; in HTML and SGML formats. The file faq-all.tgz contains all the files for easy downloading. incoming Directory where you can upload contributions . install Directory with installation related files and directories.. install/redhat Directory with files required to create a &rhppc; or &rhrc; system. install/debian Directory with files required to create a &debian; system. kernels Directory with kernel binaries and diffs. latest Directory with links to the newest kernel binary and booter. misc Directory with miscellaneous tidbits, such as the build tools I'm using to make the precompiled kernel images. The &linapus; kernel mailing list is also hosted by &sunsite;. Send for help at linux-apus-help@sunsite.auc.dk. The list is also available via NTTP from sunsite.auc.dk (look for sunsite.linux.apus). Please read before posting to this list. The apus directory at &sunsite; is mirrored a few places thanks to the people mentioned in parenthesis: Poland (FTP): snickers.ek.univ.gda.pl/pub/apus (Bartek Kozakiewicz) Italy (FTP): ftp.unina.it (Massimo Gais) If you have the space (and time?) to make a mirror of either the apus directory at &sunsite; or make an archive of the &linapus; kernel mailing list, please let me know. &sunsite; is close and convenient to use for me, but that may not be so for others. Hi guys. Here are all the developer specific chapters. I'll get it cleaned up eventually. Your job to write new sections/chapters if you see the need (or at least let me know of any text you think could be helpful). Well, you know the drill... This section describes how you can recompile your own kernel. It may be necessary to do if the prebuilt kernels do not contain drivers for some of your equipment. Rebuilding the kernel including only drivers for the equipment you have may also result in slightly more memory available for applications. The diff files found at &sunsite; are relative to the last release of the &linm68k; developer sources. The diffs are named linux-2.1.115-m68k-YYMMDD.diff.gz (2.1.115 is the current &linm68k; version at the time of writing - you may find patches for more recent kernels). Always apply my patches to a clean set of &linm68k; sources as found on &sunsite; to avoid getting rejects. My diffs may include (parts) of patches posted to the &linm68k; kernel list. I have also started uploading &linapus; relative diffs. These are named linux-apus-YYMMDD.diff.gz and are relative to the previous &linapus; release. Both because the precompiled kernels are so big, and because the set of included drivers may change without notice, you should recompile your own customized kernel when you have used a precompiled kernel to install your system. If you want to help (actively) with the development of &linm68k; and/or &linapus; you also need to recompile your own kernel (yes, you can hack the kernel. All that is really required is build tools, patience, a bit of interest in the subject and possibly some C knowledge (I learned C by hacking &linux; -- see the two previous requirements :)) It is possible to get a reasonable stable kernel by following the advice below. Many people who have problems with the kernels they build themselves usually didn't follow the below advice. In particular, use the specified tool versions even if newer are available. And build the tools yourself since prebuilt tools may include patches that could foul things up. You can find binutils at prep.ai.mit.edu or one of its mirrors (e.g., sunsite.auc.dk/mirrors/prep.ai.mit.edu/pub/gnu/). You can find egcs at egcs.cygnus.com or one of its mirrors (e.g., sunsite.auc.dk/mirrors/egcs.cygnus.com). Still, since it is a developer kernel, your mileage may vary, even if you painstakingly follow the below. Note: There has been reported problems with rebuilding egcs-1.1 from the source code archive; it requires a C++ compiler, even if you specify LANGUAGES to only include C. Workaround is to build everything (i.e., don't use the LANGUAGES option). A good way to start compiling your own kernel is by using the configuration I use to build kernels. That way, you can be sure that the kernel will build without problems, and you can test that it works just as well as the ones I have built. First patch the kernel: tar xzf linux-2.1.115.tar.gz cd linux-2.1.115 patch -d. -p0 < .../linux-2.1.115-m68k-980814.diff Then copy the .config from one of the archives with precompiled kernels to the kernel directory, configure and build the kernel: cp [path of prebuilt kernel]/.config . make oldconfig make dep make Now test the kernel. If it works, reconfigure to suit your system and rebuild. Resolve problems as they appear and send patches to the list :) If you know how to recompile &linm68k; there shouldn't be much of a difference - except that it will be done faster :) Get binutils-2.9.1 and egcs-1.1. Configure, build and install binutils. tar xzf binutils-2.9.1.tar.gz cd binutils-2.9.1 ./configure make make install cd .. Configure, build and install egcs. tar xzf egcs-1.1.tar.gz cd egcs-1.1 mkdir build cd build ../configure make LANGUAGES=c make LANGUAGES=c install Get the latest &linm68k; kernel sources (2.1.115 as of the time of writing) and apply the &linapus; patch. tar xzf linux-2.1.115.tar.gz cd linux-2.1.115 patch -d. -p0 < .../linux-2.1.115-m68k-980814.diff Configure and compile the kernel. make config [select the options you want] make dep make Boot your shiny new kernel (see ). This is probably what you want to do if you want to do some serious &linapus; development as it cuts down the time of the build-boot-test cycle dramatically. You need a slave box (like my PC 'Concubine') on which you do the editing and building and a proper connection to the &amiga; (I used serial for some months, but can warmly recommend an Ethernet card). Using a different build machine also allows you to get serial output from the kernel you are testing and/or use a remote debugger (beats printk-debugging, I'm sure) if you connect the machines with a null-modem cable. You need a cross compilation environment, targeting big-endian &cpuppc; ELF files. Here's how to build the required binutils and compiler on another &linux; box: Get binutils-2.9.1 and egcs-1.1. Configure, build and install binutils for target tar xzf binutils-2.9.1.tar.gz cd binutils-2.9.1 mkdir build cd build ../configure --target=powerpc-unknown-linux make make install You should now have binutils targeted for &cpuppc; installed in /usr/local/powerpc-unknown-linux. Get the files from /usr/include of your &linapus; box and put them in the /usr/local/powerpc-unknown-linux/include directory of your build machine. (The files are also available from .) Make sure that the asm and linux links point to the location of those directories in the linux source code you are trying to compile. Configure egcs for cross-compilation. tar xzf egcs-1.1.tar.gz cd egcs-1.1 mkdir build cd build ../gcc/configure --target=powerpc-unknown-linux make LANGUAGES=c make LANGUAGES=c install You should now have gcc targeted for &cpuppc; installed in /usr/local/bin/powerpc-unknown-linux-gcc. Configure and build the kernel. make config [select the options you want] make dep make Notice that the kernel will be build using the cross-compiler, powerpc-unknown-linux-gcc which automatically uses the correct &cpuppc; binutils. Copy the kernel to your &amiga;. Boot your shiny new (cross-compiled) kernel (see ). There's a cross-compiling mini HOWTO at ftp://ftp.uni-erlangen.de:/pub/Linux/680x0/docs/cross-compiling-Mini-HOWTO you can consult if you need more help. The obsolete ways of installing. Keeping it in the developer part for a few more months And depending on which installation method you choose you may also need one or more of the following: Obsolete Net Install: chrproot.tar.gz Obsolete HD Install: chrproot.tar.gz, hdinstall.lha First you will have to install a base system, so you will be able to boot &linapus; from the hard disk instead of from the ram disk - giving you more flexibility and tools to install applications. You can do this in one of two ways. Text and script by Sven Ottemann Unpack the archive: lha x hdinstall.lha Boot the precompiled kernel, using the ram disk as root. Log in as root (with an empty password) and execute these commands: mount -t affs /dev/your_ados_partition /mnt sh /mnt/hdinstall your_ados_partition is the disk partition where the script is located. On a SCSI disk "HD0:" this would be "/dev/sda1" and on an IDE disk it would be "/dev/hda1". This presumes you are using the first partition on the first hard disk in the chain; increase numbers for next partition (HD1: = /dev/sda2) and "increase" letters for next disk (/dev/sdb1). The files from the hdinstall.lha archive should be in the root of this drive (i.e., not hidden away in some subdirectory). path is the path to where the hdinstall script is located. See further down for details about the questions asked by the script. The generic &linppc; net installation (see www.linuxppc.org/help/install_help/PReP/network_install.cgi) can fortunately be used without too much hassle under &linapus;. This used to be the only way to install the minimal system before the hdinstall script was made. If you're not a true warrior, the hdinstall method is probably the smartest way of installing a system - and it doesn't require an extra &linux; box as this method does. I didn't scare you off? OK, then you should read the documentation (see link above). A few hints: put the chrproot archive on the slave box (remains compressed), write IP stuff down and generally follow your hacker instincts. Boot the precompiled kernel, using the ram disk as root. Log in as root (with an empty password) and execute this instruction: crdisk-net Now the script should be running. It's pretty simple to use; you are asked a handful of questions and when done (if you passed the test :) it will install the files from the minimal file system archive on your new root partition. The things to be careful about are: When the disk partition program is started: quit it. You should already have prepared the partitions under &ados;. Options for mke2fs: you might want 1kB blocks. When the script asks for install disk: replace with hda/hdb/sda/sdb as appropriate. See kernel-options.txt for help on the device names. When the script asks for the root and swap partitions: enter the right partitions. When you have installed this minimal system, you are ready to install packages. When you have installed the minimal system, reset the machine (the hard way) and reboot the kernel, but replace the /dev/ram/ part of root=/dev/ram with whatever device you installed the root system to (e.g., /dev/hdb1). This will boot &linapus; using the hard disk as boot device. Mount a drive with the &rpm; packages. Install them in alphabetic order by using a small rune like: for f in `ls /path/*.rpm`;do rpm -ivh --force --nodeps $f;done If you are a bit more on the exotic side, it can also be done via FTP. First make a list of package names you want to install, then do: for f in `cat list`;do rpm -ivh --force --nodeps ftp://ftp:foobar@ip-address/path/$f;done where ip-address and path must be replaced with whatever is appropriate for your system. The kernel contains bugs. Period. Fact of life. Some are just small annoyances, others are show stoppers. Bugs in the latter category are usually (and fortunately) easy to track down given enough information. In this section I will try to explain what you need to report when you find a bug so it is easier for others to fix it. If you feel like looking into the problem yourself (please do!) this may be used as a brief guide of what to look for. Newer kernels contain a stub which makes it possible to debug the kernel in &gdb; via a serial line from another &linux; host. This is the way to debug something since you have access to registers and memory while the system is still alive - or at the time of its death. [Unfortunately, I don't know if this interface is working properly. I hope to get it tested RSN. I will add some more text about it when I know more.] Sometimes interactive debugging is not an option and you have to rely on printk calls. Basically you insert some printks with different texts in places of the kernel where you suspect there is a problem. You can ouput variable values and thereby check that the values are what you expect them to be. Output strings throughout the flow of a function to check that it executes the expected if-statements, does the correct number of iterations or to get an idea of where it hangs. Use your imagination and be generous - each time you decide to insert more printks you have to rebuild the kernel and reboot; you might as well put in plenty to start with. Debugging head.S is a bit more tricky. I use a handful of serial-print assembly routines by Roman Zippel. These can be found in the file arch/ppc/kernel/debug.h - include it from head.S, call initserial from somewhere in the top of the code and use the other functions to output characters/values where you want to investigate something. You must use functions foo when memory mapping is disabled and functions foo2 when memory mapping is enabled. The text from the printks go to the console. Sometimes it makes sense to output the text to memory so you can save it for later reference or analysis. Use debug=mem as an option to bootstrap when booting and after reseting, run &dmesg; (from ) under &ados;. It should find the text. You can also use the option debug=ser which will output the text over the builtin serial line at 9600 baud. If a user application causes an exception it will be terminated without affecting any other application running. However, if the kernel causes an exception there is no way of handling it gracefully. In those situations the kernel will dump some information on the console which may help developers track the problem down. It may look like this: NIP: C00D4EA4 XER: 00000000 LR: C00D6E64 REGS: c3c83bd0 TRAP: 0700 MSR: 00089972 EE: 1 PR: 0 FP: 0 ME: 1 IR/DR: 11 TASK = c3c82000[130] 'mingetty' mm->pgd c2856000 Last syscall: 4 last math 00000000 GPR00: 00000000 C3C83CC0 C3C82000 C02C2FC0 00000002 00000000 00000019 00000050 GPR08: 00000000 C01528B4 C02C2FC0 00000000 3004E158 0024BB94 C017C6E0 C017C6E0 GPR16: C3EAC000 00000002 C0150000 C01704F8 00000001 00000000 00000000 C3C83D8A GPR24: 00203578 C3F5C4A0 00000001 00000000 C02C30D4 00000000 000007D0 00000000 Call backtrace: C004D580 C00D6E64 C00D7C94 C00D8710 C00CA630 C00CC4F4 C00C7988 C0026818 C000447C 00201570 00201D18 002010B8 Kernel panic: Exception in kernel pc c00d4ea4 signal 4 Rebooting in 180 seconds.. The NIP (next instruction pointer) tells what instruction caused the exception and the contents of the other registers can help explain why. The call backtrace shows the call sequence resulting in the exception allowing you to examine those functions (in the source code) and possibly insert a breakpoint (&gdb;) or printks to help track down the problem. However, since these addresses are specific to the kernel you are running, a dump like the above is not necessarily of much help to kernel hackers. In order to help them you need to use the tool ksymoops (source found in the scripts directory of the kernel sources) which will use the System.map file to produce a more usable dump you can send to the kernel list. When you have found out which function the exception was caused by (look up the address in the System.map file) you might be able to make a quick fix. If the function belongs to a driver that is not properly supported you can disable it when doing make config. If the driver accepts kernel options you might want to use some other options than the default or the ones you used when the exception occurred. The exception you experience may be caused by many things. Kernel hackers may have an idea of what is most likely to be the culprit. You can help them narrow down the list of potential problems by including the following information: The bootstrap line you use to start the kernel (so we can see what options you used). The output from bootstrap when using the -d option (so we can see what configuration you have). The kernel debug output (use debug=mem and &dmesg; as described earlier). If you need to do something in particular to cause the exception, tell us so we can try to reproduce it.